Web Example | Invoicing
This web design example comes from a workflow for a payments prcoessing call center application, specifically an invoicing workflow within the application. Nearly all use cases for applying payments to invoices in this workflow relied upon automation to apply payments per client-defined parameters (paying oldest invoices first, for example). This design, however, was meant to address a specific but key fringe case where payments needed to be manually assigned to particular invoices.
The task was to design a call center workflow that allowed customer service representatives to assign recieved payments to outstanding invoices either while on a phone call with a client representative or while working from correspondence from the client. Based on this call center design, a self-service workflow design would then follow.
As this workflow would be an addition to an existing application with a supporting design system, the initial wireframes were actually prototypes developed in Axure based off of preexisting workflow designs.
In researching the user needs and business requirements, I identified four possible scenarios for applying payments to invoices:
• One payment to one invoice
This would be a happiest of happy paths. No selection would be necessary, the user would simply be presented with a confirmation that the payment should be applied to the invoice with an input field defaulted to the lesser of the payment or invoice amount, and the amount could be edited if needed before submitting.
This would be a happiest of happy paths. No selection would be necessary, the user would simply be presented with a confirmation that the payment should be applied to the invoice with an input field defaulted to the lesser of the payment or invoice amount, and the amount could be edited if needed before submitting.
• One payment to multiple invoices
The user would enter an amount to apply to each invoice individually, with logic in place to ensure the total amount applied to all invoices did not exceed the payment amount.
• Multiple payment to a single invoice
The inverse of the previous scenario, the user would have a input field for each payment they want to apply to the invoice.
• Multiple payments to multiple invoices
This where things get... interesting. Users would need to apply funds from multiple payments to multiple invoices without spending the same money twice.
In discussing how to approach this problem with the product owner for this workflow, I proposed spliting the process into two stages. Users would select payment(s) and invoice(s) in the first stage:
Stage 1: Selecting Payments and Invoices
After selecting the payment(s) and invoice(s) to be matched up, the user could then move on to applying the funds to ouitstanding invoices. In brainstorming with the product owner, we decided to approach the multiple payments/multiple invoices scenarios first as it would be the most complicated to develop and would serve best to determine if the needed development would be feasible.
Stage 2: Applying Multiple Payments to Multiple Invoices
And this is where the story gets cut short. Upon reviewing the initial stages of the proposed design and making initial estimates on time effort needed, the development and business teams decided to shelve the project until there was a direct request from a client for the functionality.
